REMARKS 



Claims 1, 6, 7, 23, 24, and 47-57 have been amended. Claims 12-22 have been 
canceled. Claims 1-11 and 23-57 are pending in the application. Reconsideration is 
respectfully requested in light of the following remarks. 

Section 101 Rejection : 

The Examiner rejected claims 12-33 under 35 U.S.C. § 101 as being directed to 
non-statutory subject matter. Claims 12-22 have been canceled. Applicants respectfully 
traverse the § 101 rejection of claims 23-33. However, in order to expedite prosecution, 
Applicants have amended claim 23 to recite a remote procedure call system comprising 
one or more computer systems configured to implement a server and a client comprising 
a client-side remote procedure call component, wherein the client-side remote procedure 
call component comprises a client-side presentation block, a client-side encoding block, a 
client-side protocol block, and a client-side transport block. Thus, Applicants 
respectfully request removal of the § 101 rejection of claims 12-33. 

Section 102(e) Rejection : 

The Examiner rejected claims 1, 2, 4-13 and 15-57 under 35 U.S.C. § 102(e) as 
being anticipated by Lev Ran et al. (U.S. Patent 7,139,811) (hereinafter "Lev Ran"). 
Applicants respectfully traverse this rejection for at least the following reasons. 

The Lev Ran reference is directed toward a method for enabling access to a data 
resource which is held on a file server on a first local area network (LAN) by a client on a 
second LAN. A proxy receiver on the second LAN intercepts a request for the data 
resource submitted by the client and transmits a message via a wide area network (WAN) 
to a proxy transmitter on the first LAN, requesting the data resource. The proxy 
transmitter retrieves a replica of the data resource from the file server and conveys the 
replica of the data resource over the WAN to the proxy receiver, which serves the replica 
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of the data resource from the proxy receiver to the client over the second LAN. (Lev 
Ran, Abstract). The Lev Ran reference describes a distributed computer system 
comprising two or more geographically-remote LANs interconnected into a WAN. The 
system includes one or more file servers, which are located on respective LANs. The 
Lev Ran reference describes a Virtual File-Sharing Network (VFN) that enables client 
computers on one LAN to efficiently access files held by file servers on other LANs. 
The VFN comprises two or more VFN gateways, each of which is connected to a 
different LAN. The VFN gateways communicate with one another over the 
interconnection provided by the WAN. In order to serve a resource from a file server on 
a first LAN to a client on a second LAN, the VFN gateway on the first LAN fetches the 
resource from the file server and transmits the resource over the WAN to the VFN 
gateway on the second LAN, which then serves the resource to the client. (Lev Ran, col. 
5, lines 10-27; also see FIG. 1 through FIG. 3). Note in particular that VFN system 20 in 
FIG. 1 and in the description, and VFN gateways 22 in the cited Figures and in the 
description, are clearly distinct from clients 28 and servers (e.g., servers 25, 26, 27, and 
31). 

Regarding claim 1, contrary to the Examiner's assertion, Lev Ran fails to teach a 
remote procedure call system comprising a presentation block configured to present data 
types and Application Programming Interfaces (APIs) available to a program on the 
system. The Examiner cites Lev Ran, col. 56, lines 12-67, Figure 12, col. 56, lines 19-25, 
col. 58, lines 40-67, col. 62, lines 5-16, and col. 56, lines 36-39. In particular, the 
Examiner appears to cite Application Transport Layer 46 as being equivalent to a 
presentation block. In col. 21, lines 21-33, Lev Ran discloses that an application 
transport layer 46: 

...provides services for activation of remote services and inter- VFN 
gateway communication. The remote services are used by adaptation layer 
45 and the higher transmitter and receiver application layers... 

In Col. 56, lines 6-11, Lev Ran further discloses that an application transport layer 

46: 



10/677,434 (5681-64301/P9233) 



17 



Meyertons, Hood, Kivlin, Kowert & Goetzel., P.C. 



...is a framework for activating remote services used by the higher VFN 
application layers (adaptation layer 45 and VFN transmitter and receiver 
application layers 42 and 40). The application transport layer provides 
services that enable the different application layers to transfer data to 
and from one another . 

Thus, it is clear that application transport layer 46 is a framework for enabling 
different components internal to VFN gateways 22 to transfer data to and from one 
another. In contrast, the presentation block recited in claim 1 is configured to present 
data types of and APIs to the remote procedure call system to a separate and distinct 
program on the system on which the remote procedure call system is implemented. 

The Examiner cites Lev Ran, col. 56, lines 19-25, and appears to assert that "RPC 

request messages" are equivalent to "[presenting] data types." The cited reference does 

not teach or suggest that RPC request messages arc used to present data types available 

to a program on the system. The Examiner also cites Lev Ran, col. 58, lines 40-67, and 

states "java object. . .object class or type". It appears to the Applicants that the Examiner 

is equating "java object. . .object class or type" to "data types". Applicants note that col. 

58, lines 40-67 is from a section of the Lev Ran reference titled "Encapsulation", a 

section describing the data encapsulation layer 164, which performs 

serialization/deserialization. Col 58, lines 53-54 disclose that: 

Each object class, or type , preferably has its own serializer and 
deserializer. 

Applicants fail to see how this citation has anything to do with presenting data 
types available to a program on a system. Lev Ran clearly does not teach or suggest that 
the application transport layer 46 presents "java object... object class or type" to a 
program. 

The Examiner also cites Lev Ran, col. 62, lines 5-16, and quotes from that 
selection "...empty RPC request object...". It appears to the Applicants that the 
Examiner may be equating "empty RPC request object" to "data types". This citation is 
from a description of FIG. 14, which Lev Ran describes as "a method for processing an 
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RPC request by [an] RPC client" (col. 62, lines 5-6). Note that the snipped quote from 
the section comes from a sentence reading in part "The RPC client requests an empty 
RPC request object c. . ." Applicants fail to see how this citation, in which an RPC client 
is described as requesting an empty RPC request object, has anything to do with 
presenting data types available to a program on a system. 

The Examiner also cites Lev Ran, col. 56, lines 36-39, and quotes from that 
selection Application transport layer 46 "...simple API...". A more complete context of 
that quote is: 

The application transport layer provides a simple API to its higher-level clients . . . 

As noted above, it is clear from the Lev Ran reference that application transport 
layer 46 is a framework for enabling different components internal to VFN gateways 22 
to transfer data to and from one another. Thus, its higher-level clients are other layers 
and components of the VFN gateways 22 themselves. In contrast, the presentation block 
recited in claim 1 is configured to present APIs to the remote procedure call system to a 
separate and distinct program on the system on which the remote procedure call 
system is implemented. 

Thus, it is clear from the Lev Ran reference that application transport layer 46 is a 
framework that exposes interfaces to components of Lev Ran's VFN system internally to 
other components of Lev Ran's VFN system. In contrast, the presentation block recited 
in claim 1 is configured to externally present or expose data types and APIs to the 
remote procedure call system to a program on the system that is separate and distinct 
from the remote procedure call system. 

In further regard to claim 1, contrary to the Examiner's assertion, Lev Ran fails to 
teach a remote procedure call system comprising a... protocol block configured to frame 
the encodings to denote the intent of the outgoing messages. The Examiner cites Lev 
Ran, col. 61, lines 53-59 in support of this assertion. The Examiner appears to equate 
"RPC protocol manager" with protocol block as disclosed in claim 1 of the instant 
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application. The citation provided by the Examiner states that RPC protocol manager 
176: 

...handles network conditions (such as application failures, lost messages, 
out-of-order delivery, and method dependencies) in a generic manner. The 
RPC protocol manager includes, for example, a retransmission mechanism 
on the client side, and a response cache on the server side to aid in 
implementing at-most-once semantics for some requests. 

Applicants can find nothing in the above citation that teaches or suggests anything 
like a protocol block configured to frame the encodings to denote the intent of the 
outgoing messages . Lev Ran's RPC protocol manager "handles network conditions"; it 
is not described as performing any task similar to framfingj the encodings to denote the 
intent of the outsoins messages . The only thing Lev Ran's RPC protocol manager 176 as 
described in the provided citation appears to have in common with the protocol block 
recited in claim 1 is that both include the word "protocol". 

Applicants note that Application Transport Layer 46 and Adaptation layer(s) 45, 
as well as the other elements illustrated in FIG. 12, are components of VFN transmitter 
52 and VFN receiver 48, which are components of VFN gateways 22, which are in turn 
instantiated on VFN systems 20, which as noted above are clearly distinct from other 
clients and servers in Lev Ran's system (see, for example, FIGs 1 through 3). As noted 
above, the Lev Ran reference describes a Virtual File-Sharing Network (VFN) that 
enables client computers on one LAN to access files held by file servers on other LANs. 
The VFN comprises two or more VFN gateways , each of which is connected to a 
different LAN . The VFN gateways communicate with one another over the 
interconnection provided by the WAN. In order to serve a resource from a file server on 
a first LAN to a client on a second LAN, the VFN gateway on the first LAN fetches the 
resource from the file server and transmits the resource over the WAN to the VFN 
gateway on the second LAN, which then serves the resource to the client. In contrast, the 
remote procedure call system recited in claim 1 of the instant application is described as 
being implemented in memory on a system, and as exposing APIs and data types to 
programs on the system . The remote procedure call system is configured to, on behalf of 
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a program on the system , encode representations of the data types, frame the encodings, 
and transport the messages from the system to a remote system over an interconnect. 

Applicants remind the Examiner that anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim . M.P.E.P 2131; Lindemann Maschinenfabrik GmbH v. American 
Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must 
be shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). Nowhere does the Lev Ran reference 
disclose "each and every element of the claimed invention" (claim 1 of the instant 
application) as is arranged in the claim. Indeed, nowhere does the Lev Ran reference 
disclose the various elements from the Lev Ran reference cited by the Examiner 
arranged in any way resembling the elements of claim 1 of the instant application. 
For at least the reasons given above, Lev Ran clearly does not anticipate Applicants' 
claim 1 . 

Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 1 also apply to claims 23, 34, 36 and 47. 

Regarding claim 2, contrary to the Examiner's assertion, Lev Ran fails to teach 
wherein the protocol block is further configured to determine the intent of the encoded 
and protocol framed incoming messages. The Examiner cites Lev Ran, col. 61, lines 53- 
59 in support of this assertion. Again, the Examiner appears to equate "RPC protocol 
manager" with protocol block as disclosed in claim 2 of the instant application. 
Applicants can find nothing in the citation provided by the Examiner that teaches or 
suggests anything like a protocol block configured to determine the intent of the encoded 
and protocol framed incoming messages . Lev Ran's RPC protocol manager "handles 
network conditions"; it is not described as performing any task similar to determinfingj 
the intent of the encoded and protocol framed incoming messages . 
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In further regard to claim 2, contrary to the Examiner's assertion, Lev Ran fails to 

teach wherein the presentation block is further configured to provide the data types from 

the incoming messages to the program on the system. The Examiner cites Lev Ran, col. 

56, lines 16-25 in support of this assertion, and appears to equate "...response 

messages. . ." with "data types from the incoming messages." The context of that snipped 

quote from Lev Ran is: 

Remote services are activated by bidirectionally transferring remote 
procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client. 

The above citation does not teach or suggest anything like a presentation block 
[that] is... configured to provide the data types from.. .incoming messages to [a] 
program on the system. In the citation, the RPC response messages are sent from an 
RPC server to an RPC client in response to RPC request messages sent by the RPC client 
to the RPC server. An RPC client is a "client application transport layer... on one VFN 
gateway." Lev Ran further describes the client application transport layer (RPC client) 
beginning at col. 61, line 20. Note that the RPC client is clearly disclosed as a 
component of Lev Ran's VFN system, and not as a program separate from the system. 
The RPC client and RPC server components exchange RPC request and RPC response 
messages internal to Lev Ran's VFN system. Neither one of the components is described 
as providing the data types from incoming messages to a program on the system. 

Thus, for at least the reasons presented above, the rejection of claim 2 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 2 also apply to claims 26, 35, 39 and 50. 
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Section 103(a) Rejection : 



The Examiner rejected claims 3 and 14 under 35 U.S.C. § 103(a) as being 
unpatentable over Lev Ran in view of Merrick et al. (U.S. Patent 7,028,312) (hereinafter 
"Merrick"). Applicants respectfully traverse this rejection for at least the following 
reasons. 

Regarding claim 3, contrary to the Examiner's assertion, the cited art alone or in 

combination fails to teach to determine the intent of the encoded and protocol framed 

incoming messages, the protocol block is further configured to determine if the incoming 

messages are reqeuest messages or response messages. The Examiner notes that Lev 

Ran is silent on to determine the intent of the encoded and protocol framed incoming 

messages, the protocol block is further configured to determine if the incoming messages 

are reqeuest messages or response messages, and asserts that Merrick teaches that 

limitation. In support of that assertion, the Examiner cites Merrick, col. 14, lines 11-14, 

and quotes from that selection ". . .interprets. . .". That citation states: 

As shown in step 2, the server interprets the request message as a request 
to perform a particular service and performs the service. 

Applicants fail to see how the provided citation from Merrick that teaches a 
servier interprets a request message as a request to perform a particular service is 

supposed to teach or suggest the limitiation of to determine the intent of the encoded and 
protocol framed incoming messages, the protocol block is further configured to 
determine if the incoming messages are reqeuest messages or response messages, as 
recited in claim 3. The citation does not teach or suggest anything along the lines of 
determining if incoming messages are request messages or response messages. Further, 
the provided citation just says a "server" interprets the request message, and mentions 
nothing about a "protocol block" configured to determine the intent of incoming 
messages (e.g., as to whether the incoming messages are request messages or response 
messages). 
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The Examiner goes on to assert that "it would have been obvious. . .to modify the 

system of Lev Ran with the teaching of Merrick because the teaching of Merrick would 

improve the system of Lev Ran by providing a process for determining the appropriate 

output arguments for a returning responses to a client program", and cites Merrick, col. 

14, lines 34-37. That citation reads as follows: 

The client must also associate reply messages received with request 
messages sent so that it can return the appropriate output arguments from 
the service that the client program invoked. 

Applicants note that the first citation (Merrick, col. 14, lines 11-14), which refers 
to a server interpreting request messages as requests to perform particular services 
and performing the services [indicated by the request messages], appears to have little if 
anything to do with the second citation (Merrick, col. 14, lines 34-37), which addresses 
the need for a client to associate received reply messages with sent request messages. In 
other words, the first citation from Merrick does not "provide a process for determining 
the appropriate output arguments for a returning responses to a client program", as the 
Examiner appears to be asserting. 

Merrick, alone or in combination with Lev Ran, does not teach or suggest what 
the Examiner asserts it teaches in regards to claim 3. Furthermore, even if Merrick, 14, 
lines 11-14 did teach what the Examiner asserts it teaches, combining Merrick with Lev 
Ran would not solve the problem that the Examiner asserts it would solve. 

Thus, for at least the reasons presented above, the rejection of claim 3 is not 
supported by the cited art and removal thereof is respectfully requested. Applicants note 
that claim 14 has been canceled. 

Applicants also assert that the rejection of numerous ones of the dependent claims 
is further unsupported by the cited art. However, since the rejection has been shown to 
be unsupported for the independent claims, a further discussion of the dependent claims 
is not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
64301/RCK. 



Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicant(s) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: March 8, 2007 
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